Performance and scalability are among our strongest focus in WebScheduler v3 release. Since Timeline view is capable to show a wide range of data (from minutes to quarters), loading all the data at once will significantly degrade the server and client performance and ultimately slowing down the application responsiveness in overall. The problem is even more noticeable when the loaded data is relatively huge and when Quarter view mode is used.

WebScheduler 3 addresses the performance bottleneck from top to bottom by introducing smart client paging (EventPageSize),  ViewPort paging, and server paging. The smart client and ViewPort paging are designed to provide paging solution for the client-side which dramatically improves user experiences. I’ve discussed the client paging features in my previous blog post.

In this post, we’ll learn the new server paging capability in WebScheduler 3, and how you can implement it in your application. Let’s take a clear and deep down look at it.

Concept

Designed to be an enterprise-ready scheduling component, we’ve added numerous new features in WebScheduler 3 to control the data retrieval mechanism. One of the most powerful features is server paging.

Server paging is an innovative feature built to eliminate sluggish performance due to the large data download while working in Timeline view mode. With server paging enabled, WebScheduler will download only a small chunk of data based on the viewport during initial load and intelligently requests more data as users scroll downward. This means reduced page load time and increased overall application responsiveness.

Not only that – you can also combine the server paging with smart client paging, JSON serialization and other features to boost your Scheduling application performance even more.

The following screenshot shows the WebScheduler with server-side paging enabled. Notice that it will load data on demand as needed.

Benchmark Result

To compliment this post with a more realistic performance comparison, I decided to do some simple testing and provided the screenshots that show the data and response time benchmark of server-side paging. In this benchmark, I’m using HighPerformanceScheduler sample which is included in the WebScheduler’s sample.

Also keep in mind that the HighPerformanceScheduler sample is using database with 3000+ records of events with 66 resources. All events are purposely recorded within 1 month to load test the WebScheduler performance in Timeline month view.

Using HttpWatch Professional 6.1, we can inspect the data size and the content returned from server. Notice that WebScheduler with server paging enabled loads only 176KB of data. That’s nearly 10x smaller when comparing it with server paging disabled which yielded 1553KB (1.5MB).

In addition, the server paging also significantly reduces data transfer time. For instances, assuming if you have 100kb/s internet connection, the load time with ServerPaging enabled will be done in approximately 1.7 seconds. Contrary, you will need to wait at least 15 seconds or more without ServerPaging.

The beauty of server paging is that it also keeps your browser light and responsive by rendering only a small amount of data at a time. Instead of loading all 3000 events at once, WebScheduler makes efficient use of resources by loading required events on demand when the page is scrolled downward.

You might be wondering how WebScheduler detects which data to be loaded in the next request. That is where smart client paging and ViewPort paging comes to rescue. To learn more on the new performance improvements in WebScheduler 3, please see the video below.

Implementation

And here’s the best part. Taking advantage of this powerful feature isn’t rocket science – thanks to the WebScheduler’s bare-metal architecture. All you need to do is simply enabling the EnableServerPaging property in ViewSettings under the TimelineView property group.

Note: Server paging feature is only applicable when the client paging is set to ViewPort or Both. For certain scenarios with smaller data (less than a thousand of records in a month view), the server paging may not be necessary enabled so that the complete data can be transmitted in a single page load. In such scenarios, the client paging will perform data rendering immediately.

That’s all for now. I’d love to hear any comments, feedback or thoughts about this feature. Feel free to drop your comments here or post it to our forum.

Warm Regards,
Budianto Muliawan